Context aware services are often cited as essential value-added services for clients on the World Wide Web (“WWW”). These services generally fall into one of two categories, namely, Context-Aware Client-Side services, and Context-Aware Server-Side services. Context-Aware Client-Side services are provided directly to the end user by their client device with or without support from the network infrastructure. The service is provided by an application running on the client device, e.g., a street mapping application, that uses capabilities of the device, e.g., a built-in Global Positioning System receiver, and/or information stored in the device, e.g., a street map database.
Context-Aware Server-Side services are provided to the end user by an Application Server located somewhere within the global Internet-at-large using contextual information provided by the access network infrastructure or by the client device itself. One example is a display of advertisements based on the demographics of the end user. Here, the “end user” is defined as a person using the client device, an application running on the client device, or an application running on a secondary device connected to the client device.
The client-side services are specifically designed for use with client devices and may be self-contained, using contextual information gathered directly by the device itself. By contrast, server-side services are usually device-independent and are deployed far from where the client device is attached to the network. In order to offer a context-aware service, an Application Server may obtain current contextual information either from the client device itself or from another source.
The models defined by various consortiums require that the Application Server obtain contextual information for a particular client in one of three ways. The first way is by requesting contextual information from a Subscriber Profile Server (“SPS”) within a service provider's network whenever the client device accesses a service offered by the Application Server. The second method is by registering with a Subscriber Profile Server in order to receive updates from the Subscriber Profile Server whenever there are updates to (elements of) a particular client's profile. The third method is by requesting manual (re-)entry of the required contextual information by the subscriber whenever the client device accesses a service offered by the Application Server.
With the possible exception of manual entry procedures, these protocols and procedures for context-aware services are not currently in wide use throughout the Internet-at-large despite an apparent demand for such services. In part, this is because the mechanisms defined by standards bodies for interacting with the Subscriber Profile Servers are incompatible with the mode of operation employed by the majority of Internet-based Application Servers.
Techniques previously used to obtain contextual information include use of the WHOIS database, use of the Domain Name System (“DNS”) database, deconstructing routing table and the use of Hypertext Transfer Protocol (“HTTP”) cookies. Other techniques previously used to obtain contextual information include frameworks for location-based services and federated identity-based services. Various industry forums have defined (and deployed) protocols that allow an arbitrary application to access the client information maintained within a Network Access Service Provider's network. However these solutions suffer from a number of problems.
For example, the framework and protocols defined by various industry forums are not compatible with those used by the majority of Internet-based Application Servers. As a consequence, both the Network Access Service Provider and Application Service Providers incur a significant investment in order to enable and deploy context-aware services. Also, there is assumed to be a pre-existing relationship between an Application Service Provider (“ASP”) and the Network Access Service Provider (“NASP”). In particular, the ASP is registered with the NASP and must have a valid subscription to the subscriber services offered by the NASP in order to access the client profile information. Finally, the Application Server must be endowed with knowledge of the relationship between a Client Device and a Subscriber Profile Server either to register for notification of profile updates or to request profile information whenever a client of the Subscriber Profile Server attempts to access an ASP service. This knowledge does not exist in any (publicly) accessible database.
The WHOIS database identifies the business entity that owns a particular block of Internet Protocol (“IP”) addresses. Some Application Servers attempt to use this database to provide a primitive form of context-aware service by matching the IP address of a Client Device with an entry in the WHOIS database. This technique, however, also suffers from a number of problems. For example, the “location” in the WHOIS database is actually the business address of the registered owner and does not reflect the location of the Client Device itself or the location where the IP address is being used. Further, the results may be misleading, especially for large blocks of IP addresses. For example, an entire block of addresses assigned to Nortel (47.0.0.0/8) maps to “Ottawa” regardless of where in the world a Nortel address is actually used. In addition, the information in the WHOIS database is manually administered and is not dynamic. A Client Device may change its point of attachment but this will not be obvious to an Application Server until and unless the Device is allocated a new address within a different administrative domain.
The DNS database maps IP addresses to structured names and a variety of other data. Some Application Servers attempt to use this database to provide a primitive form of context-aware service by matching the IP address of a client device with an entry in the DNS database. This technique, however, also suffers from a number of problems. For instance, ownership of a “name” in the DNS database is assigned on a first-come-first-served basis. Ownership of a meaningful name does not necessarily imply anything meaningful about an IP address that appears to belong to that domain name. The results may also be misleading, especially for large blocks of IP addresses. For example, the entire block of addresses assigned to Nortel (47.0.0.0/8) maps to “nortel.com” regardless of which device is using the address and where in the world a Nortel address is actually used. Finally, the source address in an IP packet header may be transformed through Network Address Translation (“NAT”) thus obscuring any contextual information that might have been gleaned from the IP address actually assigned to the client device.
In theory, routing tables may be used to learn the topology of a network and, thus, to determine where the client device is attached to the network. In practice, however, this is not feasible for a number of reasons. First, routing information in the Internet-at-large is aggregated so that a large number of destinations are represented by a single routing table entry. As a result, the further a router or server is from the client device, the more imprecise the routing information will be. In addition, routing domains are explicitly established to prevent detailed routing information from flooding into the Internet-at-large. Therefore, many (large) subnets appear as “dark clouds” to the rest of the Internet with no visible topological information for identifying where a client device is attached.
HTTP servers usually respond to each client request without relating that request to previous or subsequent requests. “Cookies” are pieces of contextual information that a server provides to a client in the header of an HTTP response to a client data request. The client then includes that information in the header of a subsequent HTTP data request so that the server may maintain context across a series of client requests. This technique, however, also suffers from a number of problems. For example, cookies contain information related to context at the server. They cannot be used by the client to autonomously provide information to the server. While cookies can be used by the server to store subscriber contextual information, the information is usually extracted from a form completed by the subscriber. This requires an initial transaction (or set of transactions) to present and complete the form before the server can act on that information. The structure and content of a cookie is meaningful only to the Application Server that issued the cookie. Cookies cannot, in general, be used as a mechanism to share information between applications offered by different ASPs. Cookies have a limited lifetime and often do not persist beyond the lifetime of a single session between a client and a server.
It is therefore desirable to have a method and system that builds on widely-adopted protocols and transactions in order to advertise the existence of contextual information to the Internet-at-large and for disseminating both public and private variants of that contextual information.